1. Field of the Invention
The invention relates generally to computer systems that concurrently execute plural application programs on a preemptive multitasking basis.
The invention is directed more specifically to multitasking systems wherein a given application program may crash and for which it is desirable to limit the ability of a crashed application program to permanently alter data. The invention is directed even more specifically to saving data before it is damaged or destroyed by a crashed program.
2. Description of Related Art
Multitasking computer systems allow multiple application programs to execute in overlapping fashion so that it appears to a user that the programs run simultaneously.
Preemptive multitasking systems are those in which an operating system has supervisory control over the concurrently executing programs. The operating system limits the length of time that each given application program has for using system resources such as a CPU (central processing unit) or other data processing means.
Examples of preemptive multitasking operating systems include Microsoft Windows95(trademark), Microsoft Windows98(trademark), and Microsoft Windows NT(trademark), all of which are available from Microsoft Corporation of Redmond, Wash. These operating systems also permit multi-threaded execution of programs. In multi-threaded execution, a program begins executing as a first, main thread and optionally generates ancillary threads that run concurrently and interact with one another through exchanges of semaphores and other methods.
During execution, a given application program may encounter an unexpected problem which halts normal execution either in a main thread or an ancillary thread. Such problems are caused by: (a) a program attempting to access restricted (privileged) or unavailable areas of memory, (b) a program making calls to unavailable system functions or services without the ability to handle such unavailability, (c) a program jumping into a nonsense stream of execution code, (d) a program invoking a no-time-out wait for an event that never occurs, (e) a program entering into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes.
When such execution-halting events occur, artisans sometimes refer to the halted program as being xe2x80x9cstuck,xe2x80x9d xe2x80x9cfrozen,xe2x80x9d xe2x80x9ccrashed,xe2x80x9d or as having encountered a xe2x80x9cfatal error.xe2x80x9d Different flavors of these terms are sometimes associated to one class of cause as opposed to another. In this application, xe2x80x9ccrashed programxe2x80x9d will be generically applied to any and all situations in which a program encounters an unexpected problem halting normal execution, irrespective of the exact cause and irrespective of whether the unexpected halt is permanent.
The user (e.g., novice user) of a computer system typically does not care what has caused a program to crash. Such a user instead generally recognizes the xe2x80x9ccrashedxe2x80x9d condition as an apparently sudden refusal by the given application program to respond appropriately to keyboard strokes, mouse clicks, or other user interface interactions such as voice commands or hand gestures. The user may also be notified by the operating system that a crash has occurred.
The presence of a crashed program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other concurrently-executing application programs can continue to run in normal fashion even though a given application has actually crashed (as opposed to situations where the program is fine and the user merely believes it has crashed). The user continues to have access to operating system services and to the resources of other non-crashed application programs running on the computer. For example, in a Windows95/98(trademark) environment the user may hit the Alt-Tab key combination to switch to another task. The user may choose to simply end the tasking of the crashed program and thereafter restart the program afresh from its basic start-up state.
Sometimes, this close-and-restart-afresh option is not an attractive one for the user. The user may have failed (or the user may merely believe that the user has failed) to save a segment of work performed with the crashed program to nonvolatile memory (e.g., to hard disk) before the crash occurred. Closing-and-restarting the crashed program afresh may mean that the unsaved work will be lost forever. Many hours of work may have to be painfully redone to reconstruct the state of the program just before it crashed. In some instances, the pre-crash state of the application may represent non-replicatable work product such as data that had just been captured and/or transformed in real-time.
To remedy this predicament, various unfreezing techniques have been developed. These techniques attempt to revive the crashed program at least to a sufficient level such that unsaved work product may be accessed and saved either wholly or partially. Examples of such unfreezing techniques include those disclosed in the above-cited patents and patent applications.
No currently known revival technique is one hundred percent effective for all possible forms of application programs. One may make an analogy to attempts to revive a human patient by CPR (cardio-pulmonary resuscitation) after the patient suffers a cardiac arrest. In some cases, the patient is fully revived. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient regretfully prove unsuccessful. In so far as reviving a crashed application program is concerned, the end goal is not to keep the application program alive and working as long as possible, but rather to keep it alive long enough so that vital, but still unsaved, work product can be saved.
Various xe2x80x9cunfreezing programsxe2x80x9d are known in the prior art to monitor the execution of applications running on a computer and detect possible crashes of those applications. When a crash is detected, various unfreezing techniques are employed by such unfreezing programs to return crashed programs to at least partial, or full operation. One such commercially available unfreezing program is CrashGuard(trademark) available from Symantec Corporation of Cupertino, Calif.
After an unfreezing program attempts to revive a crashed application program, the crashed program may resume operation having complete, limited, or no functionality. In addition, the crashed program may perform operations improperly, despite the appearance of proper functionality. The following discussion refers to a crashed application program subject to an attempted revival by an unfreezing program as a xe2x80x9ccrashed programxe2x80x9d, regardless of whether the crashed application program is successfully revived to any extent.
The degree of functionality present in a crashed program is particularly important with respect to data modification, storage, and retrieval. If aspects of a crashed program""s user interface are corrupted, then the user may be unable to reliably perform important data manipulation operations. This may prevent the user from saving valuable work product. Alternatively, the data storage functions of the crashed program may not return to their normal pre-crash operation, despite the appearance of a fully functional user interface.
This second situation is particularly dangerous since commands, however initiated, to perform simple data manipulations may inadvertently corrupt or overwrite valuable data due to the abnormal operation of the crashed program. For example, a command to save a newly edited copy of a file may cause the crashed program to overwrite the previous version of the file with erroneous, useless data. Thus, there is a need to protect against data loss caused by the operations of a crashed program revived to less than complete functionality.
As mentioned above, various unfreezing programs exist in the prior art. However, the methods utilized by these prior art programs do not necessarily protect a user""s original pre-crash data from damage caused by file changing operations attempted by a crashed program. Such programs merely allow a user to save data after a crash, or employ automatic methods for doing so. Nevertheless, such programs do not prevent potential data corruption caused by faulty operations performed by crashed programs.
Other prior art programs exist which document the changing configuration of a computer hard drive. Such xe2x80x9cundo programsxe2x80x9d typically log all disk-altering events made to a computer""s hard drive. Unfortunately, these prior art programs fail to differentiate between file changes made by a crashed program, and file changes made by any other program. Furthermore, such programs do not operate directly in response to the detection of a crash. Rather, they must be loaded prior to a crash, and consume valuable computational time by indiscriminately logging all file changes or creating backup copies of files regardless of whether a crash has occurred.
Thus, the methods employed by prior art computer programs are insufficient to protect the work of a user who continues to operate a crashed program which has been revived to less than complete functionality. No prior art unfreezing program or undo program merges the concept of detecting a crashed application program with the separate concept of backing up only file system changes made by a crashed application program. Furthermore, no prior art program provides these features with the additional benefit of backing up only a select subset of file system changes made by a crashed program.
The present invention provides methods and systems for saving data potentially modified by a crashed computer program executing in a preemptive multitasking operating system environment. The invention satisfies the long-felt need to efficiently protect against data corruption caused by crashed programs running in such environments.
A method in accordance with the present invention is invoked by an unfreezing program upon the detection of a crashed program. The invention intercedes when a crashed program attempts to perform an operation that could potentially damage or destroy previously stored data. A backup copy of the data is created before allowing the crashed program to act upon the data.
A method in accordance with the invention comprises the steps of: (a) monitoring operating system calls made by a crashed program; (b) intercepting a selected group of operating system calls made by a crashed program before they are executed by an operating system; (c) logging a subset of the selected group of intercepted operating system calls in a memory; (d) creating backup copies of data potentially modified by a further subset of the selected group of intercepted operating system calls; and (e) passing intercepted operating system calls to an operating system.
Other features and aspects of the invention will become apparent from the below detailed description.